Replication Controller(older tech)

Document Why?

• High availability
• Load balancing & scaling example:

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    app: nginx
  template:
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

ReplicaSet(newer tech)

Document example:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  # modify replicas according to your case
  replicas: 3
  selector: # difference between replication controller and replicaSet
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: us-docker.pkg.dev/google-samples/containers/gke/gb-frontend:v5

why do we need selector section for ReplicaSet

• to filter and manage pods in a clearer view
• ReplicaSet manager takes considerations of existing pods with matched labels when creating replicas.

Scale

There are three ways to scale replicas

# 1.update replicas in the definition yml, then
kubectl replace -f replicaset-definition.yml

# 2 
kubectl scale --replicas=6 -f replicaset-definition.yml

# 3 NOTE: this will not update the definition file, hence the setting is not persistent
kubectl scale --replicas=6 [replicaset_name] [pod_name]